home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / iesg / 91_09_12 < prev    next >
Text File  |  1993-02-04  |  7KB  |  206 lines
  1.  
  2.  
  3.  
  4.                      IETF STEERING GROUP (IESG)
  5.  
  6.                   REPORT FROM THE TELECONFERENCE
  7.  
  8.                        SEPTEMBER 12TH, 1991
  9.  
  10.  
  11.          Reported by:
  12.          Greg Vaudreuil, IESG Secretary
  13.  
  14. This report contains
  15.  
  16.         - Meeting Agenda
  17.         - Meeting Attendees
  18.         - Meeting Notes
  19.  
  20. Please contact IESG Secretary Greg Vaudreuil
  21. (iesg-secretary@nri.reston.va.us) for more details on any particular topic.
  22.  
  23.  
  24.  
  25. Meeting Attendees
  26. -----------------
  27.  
  28.     Borman, David / CRAY
  29.     Callon, Ross / DEC
  30.     Chiappa, Noel
  31.     Crocker, Dave / DEC
  32.     Coya, Steve / CNRI
  33.     Davin, Chuck / MIT
  34.     Gross, Philip / ANS
  35.     Hobby, Russ / UC-DAVIS
  36.     Hinden, Robert / BBN
  37.     Vaudreuil, Greg / CNRI
  38.  
  39. Regrets
  40.     Almquist, Philip / Consultant
  41.     Crocker, Steve / TIS
  42.     Estrada, Susan / CERFnet
  43.     Reynolds, Joyce / ISI
  44.     Stockman, Bernard / SUNET/NORDUnet
  45.  
  46.  
  47. Agenda
  48. ------
  49.  
  50.    1) Administrivia
  51.       - Bash the Agenda
  52.       - Review of the Minutes
  53.         - July 30th - Aug 2nd. (Pending Gross's review)
  54.         - August 8th (Pending Gross's review)
  55.         - August 15th (Pending Gross review)
  56.         - August 29   (pending Gross review)
  57.         - September 5 
  58.         - Open Plenary
  59.      - Meeting Schedule
  60.      - Bi-monthly meetings>
  61.         - Special topics meetings?
  62.      - Schedule next meeting
  63.      
  64.    2) Protocol Actions (See Appendix for recommendations)
  65.       - Multi-protocol Interconnect over Frame Relay
  66.                     <draft-ietf-iplpdn-ipoverframerelay-03>
  67.      - Inverse ARP      <draft-ietf-iplpdn-inarp-02>
  68.      - IGP Applicability Statement <draft-iesg-commonigp-00.txt>
  69.  
  70.    3) Technical Management
  71.       - Routing Architecture discussion (Noel)
  72.       - Routing Criterion Document
  73.  
  74.  
  75. Minutes
  76. -------
  77.  
  78. 1) Administrivia
  79.  
  80. 1.1 Bash the Agenda
  81.  
  82. The X500 protocol recommendations were deferred until next week
  83. so that Ross Callon could participate.
  84.  
  85. 1.2. Approval of the Minutes
  86.  
  87. No action was taken on the large set of non-approved minutes.  The
  88. IESG is still waiting for Phill Gross's editorial comments.
  89.  
  90. Minutes for September 5th were not available for review.
  91.  
  92. 1.3. Bi-weekly meetings
  93.  
  94. The IESG has been meeting weekly for many months now.  This aggressive
  95. schedule was begun to reduce the backlog of actions in the beginning
  96. of this year.  To reduce the time demands on area directors and the
  97. IETF Secretariat, the IESG will reduce it's meeting rate to every
  98. other week.
  99.  
  100. 1.4 Schedule Next Meeting
  101.  
  102. The next teleconference was scheduled for September 19th, and a second
  103. teleconference was scheduled for October 3rd.
  104.  
  105. 2.1. Multi-protocol over Frame Relay
  106.  
  107. The IESG requested the author of the multi-protocol interconnect
  108. document to change the emphasis of the document to IP over Frame
  109. Relay.  The IESG requested this change in deference to what it saw as
  110. IAB desire to limit the scope of the document to IP issues and to
  111. avoid usurping the authority of other standards bodies to make
  112. standards for Frame Relay.  The working group chairman and the author
  113. of the document reacted strongly to this change in emphasis arguing
  114. that liaison with the relevant standards bodies has occurred and the
  115. issues raised by the IAB have been addressed in the document as it was
  116. submitted.
  117.  
  118. #
  119. # 45 minutes worth of stuff on IESG-IAB Interaction Pen-Up'ed
  120. #
  121.  
  122. In resulting dialogue, it became clear to the IESG that the Working
  123. Group has addressed the concerns of the IAB to the extent they were
  124. expressed in response to the IESG's heads-up message.
  125.  
  126. ACTION: Vaudreuil -- Modify the Multi-Protocol Interconnect
  127. recommendation to address the concerns of the IAB in respect to liaison
  128. activities of the Working Group and ANSI.  Work with George Clapp to
  129. get the wording, and send to IAB when finished.
  130.  
  131. 2.2  Inverse ARP
  132.  
  133. The IESG reviewed the latest version of the Inverse ARP document and
  134. was not satisfied with the new working of the rational section.  To
  135. resolve this editorial matter, Noel Chiappa was tasked to work
  136. directly with the author to craft appropriate wording.
  137.  
  138. ACTION: Noel Chiappa -- Work with the author of the Inverse ARP
  139. specification to write up the wording for the rational section.
  140.  
  141. ACTION: Greg Vaudreuil -- Send the IESG recommendation immediately
  142. after posting of the Inverse ARP document as an Internet Draft.
  143.  
  144.  
  145. 3.3 Routing Criterion
  146.  
  147. The ``IESG Recommendation for Interior Gateway Protocols'' has been up
  148. for review in the internet-drafts directory for over a month, and is
  149. ready to be sent to the IAB.
  150.  
  151. ACTION: Vaudreuil -- Send the recommendation to publish the IGP
  152. statement as an Applicability Statement.
  153.  
  154. 3. Technical Management Issues
  155.  
  156. 3.1 Routing Architecture Discussion
  157.  
  158. The folks working on the Inter Domain Policy Routing protocols have
  159. expressed a desire to publish their work as a proposed standard.  This
  160. work is very interesting and deserves wider exposure and
  161. implementation.  Chiappa raised the question of whether the current
  162. routing architecture supported the deployment of this protocol into
  163. the wider internet.  Specifically, the routing architecture of the
  164. Internet was not designed with multiple exterior gateway protocols,
  165. as is evidenced by the stress in the transition from EGP to
  166. BGP.
  167.  
  168. The routing architecture of the Internet needs to change.  There are
  169. many reasons including address depletion and routing table size that
  170. are likely to cause the current architecture to collapse.  It is not
  171. clear if IDPR is the next step in the evolution of the architecture,
  172. and a commitment to this protocol as the next EGP is not wise at this
  173. time. 
  174.  
  175. The IDPR people recognize that IDPR is not yet ready to become the
  176. next EGP, but they do want to standardize the protocol and begin to gain
  177. the implementation and operational experience with the protocol
  178. normally associated with the standards track.  They are ready for IDPR
  179. to become a "real" protocol.
  180.  
  181. The Internet does allow for multiple standard protocols, especially
  182. where they can operate independently.  IDPR does have the constituency
  183. and appears to have the maturity to become a proposed standard based
  184. on Hinden's criterion for standardizing routing protocols. The
  185. question for the IESG is whether the IDPR protocol and the other EGP's
  186. can in fact work independently.
  187.  
  188. Chiappa described the following possible "states".
  189.  
  190. 1) IDPR is an experiment but it is not "real".
  191.  
  192. 2) IDPR is the best long term solution and migration should begin as
  193. soon as possible.
  194.  
  195. 3) There may be 2 or 3 standards for different EGP's and idpr's with no
  196. architecture.
  197.  
  198. 4) Make a new architecture which allows "Megadomains with ouija board glue".
  199.  
  200. There is no consensus on a meta-routing architecture, and in it's
  201. absence the IESG felt handicapped in guiding the work of routing
  202. protocol development.  In the absence of any guiding principles, the
  203. IESG felt that IDPR should get all the implementation and operational
  204. experience possible and welcomes all measure to make this happen.
  205.  
  206.